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The paper will present a brief background of the previous data acquisition system at the 
National Transonic Facility (NTF) and the reasoning and goals behind the upgrade to the 
current Test SLATE data acquisition system. The components, performance characteristics, 
and layout of the Test SLATE system within the NTF control room will be discussed. The 
development, testing, and integration of Test SLATE within NTF operations will be detailed. 
The operational capabilities of the system will be outlined including: test setup, 
instrumentation calibration, automatic test sequencer setup, data recording, communication 
between data and facility control systems, real time display monitoring, and data reduction. 
The current operational status of the Test SLATE system and its performance during recent 
NTF testing will be highlighted including high-speed, frame-by-frame data acquisition with 
conditional sampling postprocessing applied. The paper concludes with current development 
work on the system including the capability for real-time conditional sampling during data 
acquisition and further efficiency enhancements to the wind tunnel testing process. 
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I. Introduction 

T HE National Transonic Facility (NTF) is a 
driven, closed circuit, pressurized, 
cryogenic wind tunnel (Fig. 1). The wind 
tunnel houses an 8.2 ft by 8.2 ft (2.5 m by 2.5 
and 25 ft (7.6 m) long test section that 
accommodates both semi- span and full span 
models. The facility also has the ability to 
independently control temperature, pressure, 
fan speed, which allows the isolation and study 
compressibility, viscous, and aeroelastic 
effects. The facility can operate in two modes, 
and nitrogen. During air operation, cooling is 
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achieved using cooling coils (water-fed heat exchangers) located in the upstream end of the settling chamber. During 
nitrogen operation, nozzles located upstream of the drive fan spray evaporated liquid nitrogen (LN 2 ) into the tunnel 
circuit. Using both of these modes, the NTF’s temperature can range anywhere from -250°F (-157°C) to 150°F (65°C). 
The facility’s drive system allows for responsive Mach control through the use of fan RPM and variable inlet guide 
vanes (IGVs) to achieve the needed compression ratio to maintain speed. This allows the NTF to achieve Reynolds 
numbers ranging from 2 to 145 million per foot (6.6 to 457.6 million per meter). The NTF houses a circular arc sector 
and roll drive to maneuver full-span models over angle of attack ranges between -1 1.5° and 19° roll ranges between - 
180° to 180°. 

The NTF upgraded its data system to the Test Software Laboratory and Automated Testing Environments (Test 
SLATE) software from an Open Architecture Data Acquisition System (OADAS) that had been in place since 1994. 
This upgrade was needed for the following reasons: the hardware and operating system was no longer in production 
or supported, new hardware could not be accommodated into the system, OADAS did not meet NASA’s IT Security 
requirements, and it could not support new computation requirements. At the heart of this system were MODCOMP® 
REAL/STAR 2000 computers running a real-time operating system called REAL/IX. This operating system was based 
on standard UNIX with real-time extensions and primarily utilized the Fortran programming language. 

The new data system runs Test SLATE®, a highly flexible DAS program running on Windows 7® PCs without 
any need for proprietary hardware. It can be used with nearly any measurement or control DAS hardware, while being 
able to coordinate multiple systems simultaneously. Test SLATE is also used at many other facilities at the Langley 
Research Center (LaRC), providing some common elements between systems. At the NTF, this new system interfaces 
with the same hardware as the old system: two PSI 8400s, Neff 620/500 controllers, and Neff 620/600 Data 
Acquisition Units (DAUs). The system also collects data from a PC-based Temperature Monitor Scanner system and 
three sequencers consisting of Programmable Logic Controllers (PLC). 

The objectives of this new system are to enhance data acquisition methods at the NTF and ensure future 
maintainability, reliability, security, and cost effectiveness of the NTF’s DAS. The new upgrade provides the NTF 
data system with the tools needed to improve data quality, test techniques, and efficiency while providing support of 
any future customer-requested testing requirements. 

II. NTF Data System Overview 

The NTF data system consists of three 
different distributed multiple component 
systems working in tandem: a Research 

Computer System (RCS), a Process Computer 
System (PCS), and a Model Preparation Area 
System (MPA). Together, these computer 
systems provided the functionality for 
acquiring, processing, recording, and displaying 
online and offline data from the model, the 
tunnel, and the model preparation areas. Each 
system is housed in the NTF control room (Fig. 
2 ). 

The RCS data acquisition subsystem is 
Figure 2. NTF Control Room responsible for continuously collecting data from the Neff DAUs 

and 8400s as well as performing computations and displaying 
model data and tunnel parameters. Standard force and moment data are measured with strain gage balances whose 
calibrations account for first and second order interactions. Other measurements include pressures from the model, 
tunnel walls, boundary-layer rakes, etc., model angles, temperatures, Mach and other tunnel parameters. Any special 
test calculations are also included. Computations are done for cyclic or real-time data as well as static, point-based 
data. 

Since safety is a major concern in a high pressure cryogenic environment, the PCS has an elaborate alarm system. 
This system provides a channel-based alarm processing capability monitoring up to 640 temperatures for tunnel safety 
and structural integrity assessment. PLCs transmit up to 4096 discrete digital state inputs to PCS giving the state of 
various valves and switches. The PCS also communicates with and receives data from the RCS through high-speed 
reflective memory (RFM). This data is then used to control model attitude during tunnel operations. 
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The MPA is patterned after RCS and runs a subset of the RCS software to support the model preparation areas for 
model buildup, balance loadings, sting bending calculations, and other needed calibrations. Cryogenic models undergo 
further calibrations in a process known as a cryo-cycle. The calibration data collected from this process is used in later 
temperature corrections during tunnel testing. These calibrations and check-outs are performed prior to the model 
entering the tunnel to prevent any unforeseen complications, and to minimize the time required for model installation 
and instrumentation verification. 

On these three data systems, Test SLATE interfaces and communicates with external systems and programs 
through five different interfaces (Fig. 3). First, Test SLATE interfaces with the high-speed RFM to receive system 
status updates and Test SLATE data files storage events. The second interface is the Test SLATE Customer 
Application Interface Dynamic Linked Library (CA Interface DLL). This DLL is used to establish communication 
between Test SLATE and the real-time cyclic data to provide calculation updates for real-time displays and plotting. 
The third interface Test SLATE communicates with is the Microsoft© SQL Server 2008 R2® database to receive 
configuration information for the DAS hardware, instrumentation, and software. This database is queried using 
standard database tools and the Structured Query Language (SQL). The next interface is what handles producing and 
storing data files for the customer. The Point and Continuous Data Processing is used to reduce the Test SLATE raw 
data and configuration files using the MATLAB® Data Reduction (DR) component. The outputs are comma-separated 
variable (CSV) point and run files, standard interface ASCII files (SIF), and SQL database tables and entries. The 
final interface is Object Linking and Embedding for Process Control (OPC). This allows third party applications, such 
as MATLAB® and Lab VIEW®, to obtain updates for Test SLATE tags, or variables, in near real-time at rates of up 
to 10 Hz. This is how Test SLATE imports current values for NTF-specific data storage identification parameters 
(Test, Run, Batch, Point, and Data ID) from the external Test SLATE Interface Layer (TSIL). All or some combination 
of these interfaces is used in daily operation of the RCS, PCS, and MPA systems. 



Figure 3. Test SLATE Interfaces 

The Test SLATE Interface Layer (TSIL) utilizes the functionality of the Test SLATE CA Interface DLL. TSIL 
was designed to extend the functionality of Test SLATE to include NTF-specific custom application requirements. 
This particular interface provides TSIL with the needed Test SLATE configuration and application startup 
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information, real-time cyclic data transfer, and Test SLATE shutdown event notifications. TSIL is the means through 
which real-time cyclic calculations are updated; configuration, tags, and recording status information is sent to external 
clients; MATLAB DR is executed; and data updates are broadcasted to external systems. 

Separate computer systems are used for offline (post-acquisition) data reduction and the NTF’s Dynamic Data 
Acquisition System (DDAS). These systems operate separately from the Test SLATE system, but do interface with it 
or call upon data from it. The former system is used to reduce data following its acquisition. It uses a slightly different 
version of the MATLAB DR component that is used in the Test SLATE interface mentioned above due to different 
input and output requirements. Commonality among the main computation MATLAB function and objects for near 
real-time, online post-point and continuous processing, and offline data reduction reduces the software maintenance 
lifecycle costs and assures data integrity during software upgrades. The offline data reduction system allows for more 
flexibility in making post-test changes to the way data is reduced and customization in how the data are presented, as 
necessitated by the facility or requested by the customer. The latter system, the DDAS, is triggered when data is taken 
by Test SLATE and is used to record high-speed data up to 204.8 kHz. 

III. Test SLATE DAS Acceptance Testing, Integration and Change Management 

The acceptance testing for the Test SLATE DAS was directed by a detailed and incremental page test plan and 
spanned multiple months, requiring two minor revisions and software releases to complete. In addition, the produced 
software required several minor releases to complete the acceptance testing. The initial round of testing produced 90 
action items (between Test SLATE and TSIL/MATLAB DR) that were systematically resolved and re -tested. After 
all of the most critical actions items were completed and tested, an operational readiness review (ORR) panel reviewed 
the project requirements, design, and acceptance testing results to attain permission to operate the new DAS. After 
ORR action items were finalized and resolved, a wind-on NTF air mode operations test (Test 214) was executed to 
observe the operation of the completely integrated DAS and FAS systems. 

At the end of the NTF wind tunnel test, all of the revisions for the Test SLATE software source code were inserted 
into the Jacobs Technology Tech Group Configuration Management repository in Tullahoma, TN. The software 
source code baseline was inserted into the Configuration Management (CM) repository software change management 
and software revision control product IBM Rational Synergy® (Synergy). Any action items remaining from the ATP 
or the wind tunnel testing were resolved or entered as software product change requests. 

The software change management process and procedures at NASA Langley Research Center follow the center 
procedure LMS-CP-7 150.4 Class C Software document. This center procedure was developed to prescribe software 
engineering practices that follow the NASA Agency NPR 7150.2A “NASA Software Engineering Requirements, for 
non-safety-critical Class C software development, maintenance, operations, retirement, management, and acquisition 
activities”. 

Any DAS software problem is entered as a Software Change Request (CR) into the CM software change database 
system, IBM Rational Change® (Change), for review by the LaRC Software Configuration Control Board (SCCB) 
that meets weekly to assess, review, and assign the change request(s) to the software developers for resolution. The 
Change database has a link to the software revision control product Synergy that is used by the software engineering 
developers and software build managers. 

In order to comply with the 7150.4 center procedure, a separate set of software development integration and test 
platforms were identified and installed for the purpose of facilitating the DAS software release testing and DAS 
software release deployment without interrupting the current DAS operation. The two separate systems required are 
used for online software integration and software regression testing, and the offline data reduction software integration 
and software regression testing along with the NTF customer acceptance testing. 

Both the online and offline software release integration and regression platforms have NTF custom automated 
testing software to perform the regression tests consistently for each software release. The software regression tests 
are designed to test different NTF test articles and NTF operational test condition modes performed in the recent past. 
Each DAS software release requires a formal acceptance test be performed and witnessed by the NTF DAS 
stakeholders targeting the software changes implemented, in addition to the successful completion of the software 
regression tests. 
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IV. Test SLATE Overview and Test Setup 
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Figure 4. Test SLATE’s user interface and tag editor 

For test setup, configuration information, such as hardware specifications or software requirements, is entered into 
Test SLATE’s user interface (Fig. 4) by NTF’s Data System Operators (DSOs). This configuration information is then 
stored in the Test SLATE database for use in data acquisition and reduction. The Test SLATE design utilizes one 
master operating console (MOC) and many auxiliary operating consoles (AOCs) for each of NTF’s three data systems. 
The MOC contains full access to Test SLATE and is primarily used by the DSOs for managing and applying changes 
to DAS configuration settings as well as performing calibrations. Though not able to make changes to the DAS 
configuration, the AOCs contain full functionality of Test SLATE and are typically used by customers, operators, and 
test engineers for displays, double checking DAS configurations, and monitoring important tunnel parameters. 

In Test SLATE, there are various layers to test setup, starting at the top level with a “System.” A unique System 
is created for every test that will contain all relevant information associated with that test. This System contains a list 
of all necessary data sources or signal conditioning hardware (known as Subsystems) to be used in the test — for 
example, the Neff DAUs and the PSI 8400 — and coordinates these subsystems to be used simultaneously during 
testing. In Test SLATE, connections to these Subsystems are known as channels. Within each subsystem, the filters, 
signal conditioning, number and name of channels are defined. Systems in Test SLATE provide a means to create 
many different configurations using the same Subsystems. There is no limit to the number of configurations that can 
be used under each System. 

Test SLATE stores sensor information in a separate database for use by any system or configuration. In the sensor 
database, each sensor is assigned a type: load cell, motor, pressure transducer, resistance temperature detector (RTD), 
strain gauge, or thermocouple. These devices’ inputs are typically measured in volts and need to be converted to 
engineering units through a conversion method. Test SLATE contains the ability to calibrate certain transducers (such 
as the potentiometers used for roll angle determination) by taking data from the transducer and calculating a fit based 
on user inputs. This calibration is automatically stored in the sensor database for the corresponding sensor. At the 
NTF, some calibration information comes from external sources, such as non-facility groups or off-site locations, and 
is typically listed on a calibration sheet. This calibration information, such as polynomial conversion coefficients for 
specific strain gauges and pressure transducers, can be entered manually. Once the calibration information has been 
stored, Test SLATE will use the most recent calibration in data acquisition and reduction. The database also holds 
information for full scale outputs, ranges, unit information, and inventory information for each sensor. When the setup 
is completed, each system and configuration has access to the sensors defined in the database to be used as needed for 
test setup. 
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After Systems, Subsystems, and Sensors have been defined, a Test SLATE configuration is created. Configurations 
hold all information needed to define and execute a test. Defined in configurations are tags. Tags are the means through 
which the user primarily interacts with Test SLATE. There are seven different types of tags: analog inputs and outputs, 
digital inputs and outputs, frequency inputs, characters, and calculations. Tags link hardware channels (from 
Subsystems) with particular sensors and provide definitions (or variable names) to be used with real-time calculations, 
post-test data reduction, and the custom stand-alone MATLAB plotting software. Setting gains, alarms (with 
conditional limits and custom messages), display units and precision, and data storage methods are also involved when 
configuring tags. 

Test SLATE houses its 
own real-time display editor 
using its structure of 
configurations and tags. 

Under each configuration, 
the user can create a set of 
custom displays utilizing 
Test SLATE’s drag-and- 
drop format for its different 
display objects, which 
include: gauges such as 

meters, tanks and 
thermometers; charts such as 
area, x-y scatter, and bar; 
tabular and grid displays; 
and miscellaneous displays 
such as clocks, labels, and 
text boxes. To populate each 
object, the user drags an 
active Tag, which defines the 
units and precision, from a 
drop-down list into the 
object of interest. Once 

populated, the display can be customized using different display options such as font, ranges, and colors (including 
the option for different colors when reaching alarm and trip limits). The NTF has created many customized Test 
SLATE displays for every day facility use to observe important tunnel parameters (Fig. 5), LN 2 tank levels, and 
different tunnel structural conditions. NTF Test Engineers and DSOs can create a number of test-specific displays as 
needed or when requested by the customer. Test SLATE also has the ability to interface and access third-party displays 
created outside of the display editor. For example, a custom Lab VIEW® display is used for manual data acquisition 
recording and monitoring or changing the NTF-specific data-set identification parameters of test, run, point, and data 
ID. 

Finally, the Test SLATE DAS contains an automatic test sequencer (ATS). During test setup and prior to running 
the tunnel, the NTF test engineer will build a test sequence within Test SLATE to automate running of the test matrix 
created from customer requirements. The test sequencer will automate the sending of specific tunnel parameters (i.e., 
Mach, pressure, and temperature) and model (e.g., pitch and roll angles) setpoints to the Facility Automation System 
(FAS) for controlling the tunnel systems. The ATS has three modes for moving the model: roll/pitch pause, alpha/beta 
pause, and roll/pitch continuous sweep. Roll/pitch pause is the most commonly used testing mode for the ATS; it 
moves the model to a set roll/pitch angle and stops for a specified amount of time for data acquisition before moving 
to the next step in the test matrix. Alpha/beta pause mode is similar to roll/pitch pause, except it uses the model’s 
angle-of-attack and sideslip instead of the pitch and roll angles for setpoints. Continuous sweep mode “sweeps” the 
model between two setpoints at a constant rate. Continuous sweep is typically used to quickly and efficiently acquire 
force and moment or temperature data at all angles between the two setpoints. The test sequencer also automates data 
acquisition. The user defines whether to start data acquisition when all setpoints are reached or when the model or 
tunnel is nearing a setpoint according to the set tolerances. The user also defines how long data acquisition will 
continue and on what conditions the DAS will stop acquiring data. 



Figure 5. Example of a created NTF real-time display 


7 

American Institute of Aeronautics and Astronautics 





During testing, the facility staff and 
the customer can observe the status of 
the ATS through two different status 
windows (Fig. 6). One window is the 
ATS status screen, which shows the 
current polar, and which step is 
currently being executed. The other 
window contains the on-setpoint status 
(OSS) display. The OSS display shows 
whether the tunnel and model setpoints 
are on, near, or off condition. It also 
displays the current setpoint being sent 
to the FAS from the DAS. These 
windows are typically displayed on 
both the AOC computer screens and on 
a large plasma TV display located in 
the control room. 

V. Other NTF DAS Products and Features 

In addition to Test SLATE, the NTF DAS is also comprised of the Test SLATE Interface Layer (TSIL), MATLAB 
Data Reduction (DR), and the NTF-specific MATLAB Plotting Package. These three products are separate from Test 
SLATE, but are used to extend functionality of the Test SLATE product to meet custom application requirements for 
the NTF. 

TSIL interfaces with Test SLATE through the CA Interface DLL. This DLL provides three basic functions needed 
for TSIL: sending startup and shutdown event notifications, providing DAS configuration information, and managing 
real-time cyclic data transfer. Once a configuration is loaded from Test SLATE, TSIL and all related applications and 
processes automatically initiate alongside Test SLATE. 

The TSIL Interface Supervisor is the main software process and manager of all other TSIL processes and clients. 
On startup, the TSIL Interface Supervisor creates and initializes a Real-Time DataBase (RTDB) containing data on 
Test SLATE tag definitions and values, system status, and test point information. The supervisor communicates with 
Test SLATE to receive and send data updates through the CA Interface DLL. All other processes asynchronously 
communicate with the supervisor through message queues to retrieve or send these near real-time cyclic tag quantity 
updates. Each process has its own timing cycle. This supervisor also manages the initiation and shutdown of all TSIL 
processes. 

A number of processes in TSIL manage communications with external applications. TSIL maintains servers for 
TCP/IP, remote procedure calls (RPC), Send Task, Multicast, and OPC. Each method uses the corresponding 
communication protocol to retrieve and send updates to the RTDB. Send Task is a legacy communication protocol 
that is supported for legacy DAS communications. This protocol is not supported by Test SLATE and TSIL solves 
the issue of interfacing with needed legacy customer applications of the old DAS system. The Multicast process is a 
user datagram protocol (UDP) communication of Test SLATE and TSIL tag updates. External applications can listen 
for the UDP multi-cast packet to receive these updates, which is sent on a periodic basis nominally at 10 Hz. It is the 
most efficient means for the DAS to transfer data to multiple external client applications. The DDAS currently uses 
the multicast communication for data updates. OPC is generally used for communication when the external client only 
needs a small subset of tag values, such as test point identification parameters. TSIL also houses its own Java Alpha 
display, but because of this display’s slow update rate (2 Hz), it is not generally used over Test SLATE’s real-time 
displays except for diagnostic purposes. 
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MATLAB Data Reduction Computation Flow 



Figure 7. MATLAB DR computational flow 

MATLAB DR (Fig. 7) consists of three different products or processes: real-time cyclic calculations, post-point 
“online” processing, and post-run or test “offline” processing. The two former processes are controlled and triggered 
by TSIL processes. The latter of the three products is conducted on a completely separate computer system from other 
DAS machines and processes. 

The real-time cyclic calculations are maintained by a C++ process within TSIL. This TSIL process sends the data 
from the RTDB to the MATLAB DR through MATLAB’s automation server interface and MATLAB’s standard 
series of C++ DLLs. Once these calculations are performed, the process then retrieves these updated calculation values 
for the RTDB. This particular interface updates at a rate of about 10 Hz, the same update rate for Test SLATE. 

The second process, the “online” post data point processing is triggered by TSIL’s NTF Client. This process 
monitors the DAS for a data point recording event has completed and inserts an entry into the MATLAB data reduction 
queue. MATLAB DR monitors this queue and if populated, it initiates the point data reduction. The output is a comma 
separated value file on a shared network drive with the run number in its filename. The data reduction also updates 
the Test SLATE SQL Server database for use by the NTF plotting package and other external clients. 

The “offline” DR system offers flexibility in making needed post-run or post-test changes to configurations and 
calculations according to the NTF test engineers or by customer request. When data is acquired, Test SLATE places 
a RAW file of the data acquired and a snapshot of the current configuration settings into a folder on a shared network 
drive. This data folder is then moved to the separate data reduction machine for post-processing, usually after a run or 
the completion of a desired data-set. Once everything is configured to the customer’s needs, a DSO will initiate the 
data reduction process and transfer the output csv files to their appropriate location. 

Configuration between the three MATLAB DR products is similar. There is a configuration file, known as the 
Comps Config, which is separate from Test SLATE’s configuration files. The Comps Config is used to configure the 
data output file location, important tunnel and customer-requested constants, equations, and different sets of 
calculations to be performed. These calculations might include local Mach and wall pressure calculations, base 
pressure corrections, balance calculations (using the LaRC-standard and AIAA-standard balance calibrations), 
temperature compensation calculations, wind-off zero calculations, and computations for rotations and deflections. 

The offline and online portions of post-point data reduction offer further custom configuration. Two MATLAB 
functions are placed in the path for MATLAB DR: userPre and executeDRsupplemental (.m files). UserPre is typically 
used to perform initial calculations on the Test SLATE data before being used for MATLAB DR’s calculations. 
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ExecuteDRSupplemental is generally used to insert more complex calculations into the data reduction results. Custom 
functions, typically written in or converted to the MATLAB programming language, can be run using all available 
acquired data from Test SLATE and calculated data from MATLAB DR. This function is run at the end of data 
reduction, before the final output file is written to disk. To further offer customization, MATLAB DR includes a 
method for customizing the output of the customer output data file with the ability to exclude or rename tag and 
calculation definitions according to the customer’s needs. Typically these results remain in a .csv format, but can also 
be converted to other formats as necessary. 

Being on a separate computer system from the DAS, the offline portion of data reduction offers further improvement 
of data quality. Once data has been acquired, the user can make any number of configuration changes to the two .m 
files mentioned before and also to the Comps Config. The user can also decide to reduce the data in a frame-by-frame 
reduction. In a frame-by-frame reduction, each scan of data is treated and calculated independently, as opposed to 
being averaged. While the time to reduce the data is increased because of the large file sizes, the frame-by-frame 
reduction allows for much more scrutiny in the data analysis process, which can lead to better data quality for the 
facility and the customer. 

Lurther increasing data quality, the user can decide to perform conditional sampling on the frame-by-frame data for 
each test point. In this case, the data reduction excludes all scans of data where user specified tolerances on select 
variables are not met before performing any averaging in the data reduction. Typically, these tolerances are on 
pressure, temperature, and/or Mach number. With conditional sampling, the NTL DAS can greatly improve its Mach 
stability and drag repeatability between runs at the same test conditions. Currently, this feature is only available in the 
online point data reduction and offline data reduction system, but current software development is moving towards 
implementing this feature into real-time data acquisition and recording functions utilizing the ATS. Ultimately, this 
will improve facility efficiency by reducing the amount of time needed to acquire enough data that meets user 
tolerances and automatically stopping a data point once the desired number of valid frames is reached. 


To demonstrate the benefits of conditional sampling, data from a recent test (Test 218) conducted at the NTL were 
compared (Ligs. 8 and 9). The first data set (Lig. 8) shows drag coefficient repeatability for the Common Research 
Model in air mode at Mach 0.850; all data were acquired using the Test SLATE DAS system. The difference from the 
mean of the drag coefficient over three runs versus angle-of-attack is plotted in the figure below. The solid lines 
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Figure 8. Comparison of the effects of conditional sampling with tighter Mach tolerances on the repeatability of 
the drag coefficient using NTF Test 218 air mode data. The left plot is without conditional sampling. The right plot 
is with conditional sampling applied on Mach to a tolerance of 0.0005 

repeatability of the drag coefficient in air operations mode after conditional sampling methods have been applied to 
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narrow the Mach tolerance to 0.0005. Similar tests were conducted on data from LN 2 mode operations at Mach 0.850 
(Fig. 9) and the results showed a nearly 4: 1 improvement in drag coefficient repeatability after conditional sampling 
with a tighter Mach tolerance. 
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Figure 9. Comparison of the effects of conditional sampling with tighter Mach tolerances on the repeatability 
of the drag coefficient using NTF Test 218 nitrogen mode data. The left plot is without conditional sampling. 
The right plot is with conditional sampling applied on Mach to a tolerance of 0.0005 

Finally, included in the NTF DAS is the MATLAB plotting package. This plotting package was created to fulfill 
the needs of the facility, but is also available for use by customers should they desire to use it in lieu of their own 
custom plotting software. The plotting package contains the ability to customize both real-time and post-point plots 
created in MATLAB. Real-time plots connect to the OPC interface in Test SLATE to receive data updates for a subset 
of tags at a rate of 10 Hz. These plots are available in trend plots for monitoring multiple values vs. time; X vs. Y plots 
for plotting two tags against one another; bar graphs; and conditional X vs. Y plots, which only display data when a 
certain condition is being met. Post-point plots monitor the SQL database for any new points that have recently been 
acquired and processed and updates the plots with the most recent point. These are typically separated by runs (a series 
of acquired points at a certain condition), and contain all points in a run. These graphs offer the ability to display the 
current run or any previous runs taken, so long as these data points exist in the database. The plotting software also 
offers the option to manually enter legacy data into the database for use. These plots come in the form of X vs. Y 
plots, composite plots (a value plotted vs. location), and multiple y-axis plots. The MATLAB plotting package can be 
opened on any DAS AOC machine, and all settings saved are stored on a separate network drive. This allows the same 
plot to be opened on multiple machines with the exact settings or re-opened on a previously closed plot with no need 
for re-customization. 


VI. Dynamic Data Acquisition System Overview 

The NTF’s Dynamic Data Acquisition System (DDAS) is a software product developed using National Instruments 
(NI) Lab VIEW 2013 64-bit to interface with the NTF’s Pacific Instrument® (PI) signal conditioners and NI high 
speed 24-bit analog-to-digital converter (ADC) hardware for dynamic data recording. The DDAS can simultaneously 
record up to 32 different analog instrumentation channels. These signals are passed through PI model 6120 amplifiers 
for conditioning before being routed to an NI PXI-1045 chassis. The chassis is made up of a NI PXI-8336 MXI-4 
remote controller and eight NI PXI-4462 dynamic signal analyzer cards. Each NI PXI-4462 card can sample four 
analog channels at up to 204.8 KHz and has a 24-bit resolution ADC. 
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The DDAS software on the control PC additionally monitors user 
specified variables from data that is multicast from Test SLATE at a 
rate of 5 Hz. When triggered by Test SLATE or when a data point 
is manually taken from the Lab VIEW front panel, DDAS averages 
the multicast data over the user specified sample period and records 
it in a text file. This text file can be used a log to compliment the 
Figure 10. NI PXI-1045 chassis on top of the high speed data taken from the 32 analog channels. 

PI Model 6120 Amplifiers The figure below (Fig. 11) shows the DDAS Lab VIEW front panel. Note the 

configurable controls for the sample rate, plot rate, and sample period on the right side 
of the screen. DDAS data from the analog channels is constantly monitored on the graphs on the left side of the 
screen. Multicast data from Test SLATE is displayed in tabular form on the top right of the screen. Data acquisition 
can be done manually from the front panel via the grey “Take Data” button on the lower left portion of the screen. 
When triggered by Test SLATE, the green “Take Data” indicator illuminates on the lower left portion of the screen. 
The power spectrum from previously recorded data can be plotted on the screen by specifying the averaging and 
weighting mode and toggling the “Plot Spectra” button on the lower left portion of the screen. 


Figure 10 shows the NI PXI-1045 chassis on top of the PI model 
6120 amplifiers. The system here is setup to record 14 analog data 
channels and three and one half of the slots on the NI PXI-4462 cards 
are occupied. Data acquisition on the NI PXI-1045 chassis is 
controlled and monitored from a PC running Lab VIEW software that 
specifies the acquisition rate and sample period for all channels; 
separate PI software allows the user to specify filtering and 
amplification settings on the PI model 6120 amplifiers. Data 
acquisition on DDAS can be triggered from Test SLATE or points 
can be taken manually from the Lab VIEW front panel. Data files 
are stored in binary format at a location specified by the user upon 
system startup - either on the control PC or an external hard drive. 



Figure 91. Dynamic DAS Lab VIEW Front Panel/User Interface 
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VII. Current Operational Status and Future Development 

The new Test SLATE system is currently fully operational at the NTF. It was designed to keep full functionality of 
the OADAS system, while adding improved features and flexibility for future upgrades. The distributed architecture 
of the new NTF DAS enables prioritization and reasonable costing of future software and hardware improvements to 
meet the current and future needs of the NTF. The previous DAS (OADAS) was of a single node centric design that 
was very complicated (and not cost effective) to upgrade in place. The new distributed design of the Test SLATE 
DAS allows entire subsystems and components to be upgraded as funding is available. 

Current and future improvements will continue to focus on software capabilities, maintenance, and performance. 
There has been a reduction in the number of change requests for the system by nearly 80% in the most recent testing 
compared to when it was first implemented. New NTF test requirements will also drive the design, development, and 
implementation of software and hardware updates. The distributed architecture of the NTF DAS hardware and 
software design and the implementation of industry standard interface protocols, such as OPC, facilitate software and 
hardware enhancements as required for customer testing. As needed, new software products will involve an iterative 
software development cycle of design, development, careful implementation, testing, and verification. 

Finally, the Test SLATE system at the NTF offers the following capabilities: 

• implementation of the newly developed conditional sampling for data point processing and real-time data 
acquisition (the latter is currently in development), 

• improved data efficiency with the implementation of a faster averaged point and frame-by-frame data 
reduction, 

• continuous sweep data processing with phase/lag adjustments, 

• hooks and interfaces for customer- specific calculations and applications, 

• customized displays according to customer needs and requirements, 

• support of commercially available hardware and enough processing power for future hardware and 
software improvements, 

• and development on a currently supported operating system (Windows 7) meeting NASA’s IT security 
requirements. 


Disclaimer of Endorsement 

Neither the U.S. Government nor NASA endorse or recommend any commercial products, processes, or services. 
Reference to or appearance of any specific commercial products, processes, or services by trade name, trademark, 
manufacturer, or otherwise, in NASA materials does not constitute or imply its endorsement, recommendation, or 
favoring by the U.S. Government or NASA and are presented for reporting purposes only. The views and opinions of 
the author(s) expressed in this report do not necessarily state or reflect those of the U.S. Government or NASA, and 
they may not be used for advertising or product endorsement purposes. 
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